This is intended as an immediate fix to: getsentry/sentry-java#4830

However, it only fixes one instance of a signal-unsafe function used inside the inproc backend. Most issues with unsafe functions will probably not even find its way back to sentry because they just block the signal handler. So, while this fix might be enough to address the immediate problem in getsentry/sentry-java#4830 it also might only move the goalpost.

I will create another PR that changes inproc in way that splits the signal-handler in two parts:

• code that executes in the context of the signal-handler (i.e., in the preempted crashed thread) that must be signal-safe
• code that executes on a separate handler thread, that should still be written in a sensible fashion, but can use non signal-safe functions

These PRs should be merged as either/or.